Как написать свой маленький Фейсбук Написать свой маленький фейсбучек очень просто. Первое, что вам нужно взять это Эрланг. В Эрланге нету OOP, Patterns, Dependency Injection, OSGi, MVC и много другого мусора, которым вам забивают голову на работе. Там есть четыре парня: supervisor, gen_server, gen_fsm и gen_event. Эрланг мы возьмем для того, что было кому обслуживать процессы. Все процессы вашего фейсбука можно разделить на такие классы: 1. Процессы которые обслуживают пользователей. Их будет фиксированное количество. Каждый процесс в системе представляет в системе ровно ОДНОГО пользователя, не обязательно залогиненого, можно держать процессы для незалогиненых пользователей. Они всегда будут, не будт скачков при масовом логине. Все группы, пользователи, отдельные фиды (виртуальные пользователи) -- это все процессы одного типа. 2. Процессы которые обслуживают предметную область. Процессы количество которых нефиксированно и может меняться. В моем случае это игровые процессы: Игры, Сессии, Столы, Турниры и процессы обслуживающие AMF порта. К слову, все AMF порта у меня завернуты напрямую на IP:80, я считаю что дешевле купить один дополнительный IP на машину, чем заворачивать как нищеброд AMF в HTTP, т.е. говно в говно :) 3. Комет процессы. Процессы которые обслуживают веб страницы. Сдесь мы берем Нитроген. В среднем страница на нитрогене занимает 5-8КБ. Весь мой проект состоит из 4 монстрообразных страниц по 40КБ каждая. Это потолок практически для любого фейсбук-лайк хендмейд апликейшина. Что бы управлять этим всем делом нам понадобятся несколько кластеров разных уровней. 1. Кластер DHT. Riak. Риак будет хранить для нас всю информацию о пользователях, фидах. Поскольку риак не может нам обеспечить консистентности мы будем ее обеспечивать очередью запросов на запись в процессе пользователя\группы\фида, который по сути будет локом данных определенной сущности. Все операции которые состоят из более чем одного put'a будут направлятся в единственный процесс в системе который может писать по этим ключам. Riak кроме того мы будем использовать как кеш данных, встроив его в каждую ноду и пользуясь нативным Эрланг API напрямую без всяких протокол буферов и прочего булшита. Риак поддерживает секондари индексы, поэтому неоторые операции как, например подписки, баны и френдование можно делать на leveldb бэкендах, фиды и другую информацию лучше хранить в bitcask. 2. Кластер с быстрым инмемори поиском. GProc. Gproc мы будем использовать на каждой ноде для того что бы зафигачить суперсложный QLC запрос по распределенным ETS таблицам. Вы даже не представляете сколько кода может выбросить Gproc из вашего проекта. Из своего я выбросил 70КБ. А 70КБ на эрланге, в эту цифру можно уложить Amazon Dynamo имплементацию с memcached интерефейсом. Гпроц позволит вам найти похожих пользователь в вашей системе и предложить им стать друзьями, без этой функциональности ваш карманный фейсбук нафиг не кому не сдался. 3. Доставка и роутинг сообщений. Кроль. Кроль будет выполнять весь роутинг сообщений. Вот вы если подписываетесь на очереди напрямую в своем любимом Message Bus поделье вы это зря делаете. Потому что круто подписываться с условием, например все юзеры подписываться у нас будут на один эксчендж SYSTEM но с условием "username", кроль будет для наших процесиков заворачивать все сообщения, которые забинжены на этот глобальный ексчендж по нашему ключу. Все кансомеры кроля -- это и есть наши пользовательские процессы, которые заодно и являются обеспечением консистентности, а также содержат в себе все API операций записи, чтения не нужно так как чтение вы можете выполнять на любой ноде облака риака. 4. Файлики. Что бы мучаться с файликами мы возьмем glusterfs: одна строчка volume create vol replica и у вас кластер, который будет хранить все видео, пдфки и другие няшечки на вашем домашнем фейсбучике. 5. Самый быстрый Эрланг веб сервер.. В каждый момент времени самый быстрый эрланг веб сервер всегда уникальный. Сейчас это Cowboy. Поэтому я перевел свой проект с мочивеба на ковбой за 2 дня и счастлив. Теперь о том как будет происходить фейловер, апдейт и сколько машин для этого надо. Не имеет смысла начинать строить это все если у вас меньше 12 машин в кластере. Если у вас машин меньше то вы просто зря читаете этот текст. у вас должно быть минимум 3 бима кроля на разных машинах, 10 инстансов риака, 10 инстансов гпроц, три ноды к ГластерФС. Всех пользователей можно порезать на партиции (пучки), как в ЖЖ например. Каждый новый пользователь закрепляется за своим пучком на всю жизнь. При падении пучка процессов которые поднимаются бустрапером пучка, этот пучек поднимается на другой ноде средствами встроенными в эрланг. каждый пучек для этого должен обслуживать одтельное приложение с именем пучка, которое просто депендит цикл загрузки процессов для пользователей определенного пучка который совпадает с именем приложения. Поскольку каждая нода имеет в себе клиентскую библиотеку кроля, она может подписываться на сообщения и посылать сообщения, каждая нода содержит ноду риака, поэтому она может локально читать данные из своего бима сократив до минимума операции чтения. Для операций записи она должна направлять нотификации кролячьего API которые дойдут до процессов охраняющих данные пользователей и пропускающие через свою очередь все операции записи данных пользователя\группы\фида. Вы также можете с любой ноды строить моментальные сложные QLC запросы почти SQL уровня по размазанному ETS хранилищу. Все процессы регистрируются в GProc кластере и вы можете найти кого угодно в вашей системе по имени (а не по pid!) и послать ему сообщение. Вы можете с легкость выключать ноды и смотреть что ваша система не теряет отзывчивости, главное не превысить пир этом границы своих NWR параметров :) Я накатываю апдейты на рабочие инстансы, просто выключая их, и могу даже для некоторых нод поменять виртуальную машину Erlang с R14 на R15! Это не снилось даже для хот коде свапа OTP-шного. Вот и весь секрет успеха: Riak, GProc, RabbitMQ, Nitrogen, Cowboy, GlusterFS. Если вам нужен свой фейсбук обращайтесь в http://synrc.com.